1.1 Le versioning

Principe général :

Le versioning consiste à conserver la version d’une entité logicielle quelconque de façon à pouvoir la retrouver facilement même après l’apparition et la mise en place de versions plus récentes.

Sans versioning

Exemple de ce que l’on peut trouver sur un server :

1.2 Avantages du versioning

Le versioning permet de :

• Travailler collectivement sur les mêmes fichiers en même temps
  
• Obtenir de la traçabilité : on sait qui a changé quoi, quand, comment et pourquoi
• L’expérimentation lors des développements sans risques (à l’aide des branches)
• Faire de la relecture (revues de codes…)
• Voyager dans le temps

Avec une forge, il permet en plus de :

• D’archiver le code
  
• D’apporter de la visibilité à vos projets

=> Un usage qui se justifie même quand on est tout seul sur un projet !

1.3 Git

Parmi les logiciels de versioning existants, Git est le plus populaire depuis quelques années :

What are the primary version control systems you use?

Source : Stackoverflow

1.4 À propos de Git

Git est un logiciel libre de versioning.

2.1 Qu’est-ce qu’on versionne ?

On versionne les fichiers de type texte

Par exemple :

• Les programmes R, Python, SAS…
  
• La documentation au format texte, Markdown…
  
• Les fichiers quarto, Rmarkdown…
  
• Les fichiers de configuration de type yaml par exemple…

Éventuellement, on peut aussi versionner des images si on en a besoin dans une application ou une documentation.

2.2 Qu’est-ce qu’on NE versionne PAS ? (1/2)

TOUT LE RESTE :)

C’est-à-dire notamment les fichiers tableurs, de traitements de texte, les pdf, les diaporamas de type powerpoint ou impress, les fichiers spécifiques aux projets R…

Pour se faciliter la tâche, on utiliser un fichier spécifique .gitignore situé le plus souvent à la racine des projets.

Il s’agit d’un fichier texte, qui liste les fichiers et dossiers (sous forme d’expressions régulières) à ne pas versionner.

– une ligne = une règle ;

– on peut ignorer :
• des fichiers
• des dossiers
• des extensions
• …

2.3 Qu’est-ce qu’on NE versionne PAS ? (2/2)

Si vous utiliser le package R gitssp mis à disposition des agents du MASA, voici ce qui est exclu par défaut avec la fonction gitssp::creer_gitignore() :

.Rproj.user
.Rhistory
.RData
.Renviron
.Ruserdata

/* Les fichiers avec ces extensions
*.xls
*.xlsx
*.ods
*.pdfF
*.docx
*.odt
*.ppt
*.odp

2.4 Comment utiliser Git ?

3 façons seront présentées dans ce support :

• Via l’interface visuelle de l’IDE RStudio
  Pour les commandes les plus courantes du quotidien

• Via les commandes du terminal
  Pour les commandes plus avancées

• Via le package R gitssp
  Pour simplifier l’articulation avec les dépôts distants

2.5 Installer Git

• Si vous travaillez avec Cerise, Git est déjà installé.
  => Vous pouvez directement commencer à l’utiliser. (il vous faudra simplement régler votre configuration pour faire en sorte de dialoguer avec la forge interne Gitlab => voir ici)

• Si vous travaillez en local, consultez cette procédure interne au MASA

2.6 Git avec RStudio

Pré-requis : pour pouvoir utiliser correctement Git avec l’IDE RStudio, il convient d’utiliser le mode projet.

Comment savoir si un projet R est versionné avec Git ?

• Un fichier .git est présent dans l’explorateur de fichier.

• À l’ouverture du projet R, un onglet Git s’affiche dans RStudio :

=> Une utilisation de Git en cliquant sur les boutons de RStudio

2.7 Git avec le terminal

• En local, vous pouvez directement utiliser les commandes du terminal sans RStudio.

Pour cela, il vous suffit de vous placer dans le bon répertoire (par exemple avec la commande cd pour change directory).

• Sur un server Posit comme Cerise, le terminal est désormais intégré dans les sessions RStudio à côté de la console classique de R

Vous pouvez alors soit utiliser la même méthode qu’en local avec la commande cd soit de préférence :

• Vous placez dans le répertoire voulu dans l’explorateur de fichiers
  
• Cliquez sur le bouton Plus en haut à droite
  
• Cliquez sur le bouton

=> Une utilisation de Git en tapant des commandes qui commencent par git…

2.8 Git avec le package R gitssp

Un package à installer et chargé comme d’habitude.

Pour l’instant, les sources ne sont présentes que sur la forge interne du MASA :

remotes::install_git("https://forge.agriculture.rie.gouv.fr/gitlab/ssp/bmis/gitssp",
                     dependencies = T,
                     git = "external")

Par exemple, pour tester si un dossier est versionné avec Git, on peut utiliser la fonction git_projet_existe() qui teste l’existence d’un fichier .git dans le répertoire courant.

2.9 Initialiser un dossier local en dépôt Git avec RStudio

Créer un nouveau projet puis choisir un nouveau répertoire :

Après avoir choisi le nom du nouveau projet, cocher la case “Créer un répôt git” :

2.10 Initialiser un dossier local en dépôt Git avec le terminal

La commande git init permet d’initialiser un dossier avec Git

Cette commande crée un nouveau sous-répertoire nommé .git qui contient tous les fichiers nécessaires au dépôt — un squelette de dépôt Git.

Pour l’instant, aucun fichier n’est encore versionné !

2.11 Initialiser un dossier local en dépôt Git avec gitssp

Le package R {gitssp} permet d’initialiser un dossier local avec Git tout en le synchronisant avec une forge.

Cela sera abordé dans la partie 4 de cette formation.

3.1 Fonctionnement

*Source : itnext.io

3.2 Les zones de Git :

Pour évoquer le fonctionnement de Git et son articulation avec une forge, cela nécessite d’apprendre à utiliser de nouveaux termes (voir lexique diapo suivante).

• working directory : répertoire de travail de l’agent
• staging area ou index : zone tampon dans laquelle l’agent regroupe les changements en vue du prochain commit.
• local repository : dépôt local présent dans votre espace de travail (.git)
• remote repository : dépôt distant sur une forge

3.3 Les commandes principales de Git

• git add : ajout des changements à l’index
  
• git commit : enregistre les changements placés dans l’index
  
• git push : envoie les changements vers le dépôt distant
  
• git pull : télécharge les changements depuis le dépôt distant
  
• git checkout : permet de se déplacer dans l’arbre (retour vers le passé, changement de branche)

3.4 Une 2ème illustration pour fixer les idées :)

3.5 Le working directory

Il s’agit de notre copie de travail c’est-à-dire le répertoire et sous-répertoires dans lesquels se trouvent les fichiers suivis par Git.

C’est là que l’agent effectue les changements sur les fichiers.
Il correspond à votre espace de travail.

3.6 La staging area ou l’index

Zone tampon dans laquelle l’agent regroupe les changements en vue du prochain commit.

L’agent peut ajouter ou retirer les changements à l’index.

Il peut faire cela en une seule ou plusieurs opérations (voir diapos suivantes).

3.7 Ajouter des changements à l’index

Pour ajouter des changements :

Avec RStudio

• Un seul fichier : en cochant un fichier dans l’onglet Git
  

• Plusieurs fichiers : en cochant plusieurs fichiers dans l’onglet Git
  

En ligne de commande :

• Un seul fichier : git add <file-name>
• Tous les fichiers : git add .

3.8 Retirer des changements à l’index

Pour retirer des changements :

Avec RStudio
En décochant les fichiers dans l’onglet Git

En ligne de commande :

• Un seul fichier : git reset <file-name>
• Tous les fichiers : git reset

3.9 Les états des fichiers avec RStudio

L’onglet de RStudio permet d’avoir des repères visuels sur les changements apportés à chacun de vos fichiers :

3.10 Les états des fichiers avec le terminal

La commande git status affiche l’état du working directory et de l’index.

Voici un exemple d’équivalence entre les icônes RStudio et le résultat renvoyé par la commande git status :

3.11 Les états des fichiers APRÈS l’ajout à l’index

Après l’ajout de fichier à l’index, 2 nouvelles icônes apparaissent dans RStudio (même fonctionnement avec le terminal) :

Changement	AVANT l’ajout à l’index	APRÈS l’ajout à l’index
Ajout de fichier
Renommage de fichier

3.12 Comment Git stocke les différentes versions d’un fichier ?

“À chaque fois que vous validez ou enregistrez l’état du projet dans Git, il prend un”snapshot” du contenu de votre working directory à ce moment et enregistre une référence à ce snapshot. Pour être efficace, si les fichiers n’ont pas changé, Git ne stocke pas le fichier à nouveau, juste une référence vers le fichier original qu’il a déjà enregistré.”

3.13 Afficher les différences avec RStudio

L’interface de RStudio permet de rapidement et facilement visualiser les changements que vous avez apportés sur le code.

Pour cela cliquez sur le bouton diff de l’onglet Git .

3.14 Afficher les différences avec le terminal

La commande git diff affiche les différences.

Pour afficher les différences sur les fichiers déjà ajoutés à l’index, la commande est git diff --staged.

Le terminal permet d’aller plus loin dans l’observation des différences, par exemple en comparant 2 commits…

3.15 Revenir en arrière avec RStudio

Dans RStudio cliquez sur le bouton Plus de l’onglet Git puis choisir le bouton Inverser :

Un message de confirmation vous demande si vous êtes sûr de votre action :

3.16 Revenir en arrière avec le terminal

La commande git restore permet de restaurer des fichiers

3.17 Le commit

Action de figer l’état du dépôt sous forme de snapshot

Un bon commit :

• Change une seule chose
• Peut être décrit avec un message clair et explicite

Erreur courante du débutant sur Git :

• Il code pendant des heures/jours/semaines
  
• Ajoute toutes les modifications à l’index avec git add .
  
• Puis il commite…

3.18 Caractéristiques du commit

• Un commit possède un identifiant unique (SHA)

Il informe les utilisateurs :

• Qui ? Quoi ? Où ? Quand ? => Avec ses métadonnées
• Quoi ? Où ? Comment ? => Avec l’affichage des différences
• Pourquoi ? => Avec le message du commit

3.19 Les messages de commit

D’après Conventional Commits, l’écriture des messages de commits devrait suivre la la structure minimale suivante :

<type>: <description>

Le tableau suivant reprend les types les plus couramment utilisés :

3.20 Comment committer avec RStudio ?

Après avoir ajouté les fichiers modifiés à l’index, il est temps de “committer” les changements c’est-à-dire de prendre une photo / un snapshot de ces fichiers modifiés.

Dans RStudio, il faut cliquer sur le bouton “Commit” de l’onglet “Git”

Puis, renseigner dans la nouvelle fenêtre qui s’affiche le message du commit et cliquer sur le bouton “Commit” :

3.21 Comment committer avec le terminal ?

La commande git commit -m "message du commit" permet à la fois de faire le commit tout en renseignant le message associé

Voici un exemple :

git commit -m "fix: ajout fichier odt dans .gitignore"

::: callout-note La commande git commit propose de nombreuses options qui sont disponibles ici. :::

3.22 Modifier le dernier commit

Il y a au moins deux raisons de revenir sur un commit :

• Modifier le message de commit (même pour une faute de frappe)
  
• Ajouter ou supprimer des fichiers au commit.

Attention ! Cette commande ne doit être effectuée que si vous n’avez pas encore poussé le commit sur dépôt distant sinon les autres utilisateurs du commit seront affectés puisque le SHA-1 est changé

3.23 Si vous ne deviez retenir que quelques commandes !

Action
Vous ajoutez vos fichiers à l’index	Cochez les fichiers	git add
Vous committez vos changements	Appuyez sur le bouton “Commit” et vous renseignez votre message de commit	git commit - m "Votre message"
Vous envoyez vos commits en local sur le serveur distant	Appuyez sur le bouton “Push”	git push origin <nom-de-branche>
Supplément si vous travaillez à plusieurs :
Récupérer les éventuels commits de vos collègues	Appuyez sur le bouton “Pull”	git pull origin <nom-de-branche>

3.24 Consulter l’historique avec RStudio (1/2)

3.25 Consulter l’historique avec RStudio (2/2)

RStudio permet facilement de :

• Balayer l’historique du projet en sélectionnant les différents commits.

• Accèder aux informations correspondants à chaque commit.

• Cliquer sur les fichiers concernés par chaque commit et afficher leur état au moment choisi.

3.26 Consulter l’historique avec le terminal

Avec la commande git log : Exemple :

C:\Users\damien.dotta\DEMESIS\Formations_Git\formation_git_2024>git log
commit efb2b38f3f4c7719201119c5bf1dea575e0621ab (HEAD -> main, origin/main)
Author: Damien Dotta <damien.dotta@live.fr>
Date:   Fri Mar 29 17:13:00 2024 +0100

    doc: ajout de ce qu'on versionne et ceux qu'on ne versionne pas

Ce qu’on y trouve :

• l’identifiant du commit
  
• l’auteur du commit (nom + email)
  
• la date et l’heure du commit
  
• le message du commit

3.27 Fréquence des commits

Quelle fréquence pour les commit ?

• Aussi souvent que possible

• Regrouper les modifications en lots qui “font sens”, avec un message pertinent qui résume bien les modifications apportées

• Il ne faut committer sur la base du temps passé mais plutôt sur la base des fonctionnalités.

4.1 Git - un modèle distribué

• Dépôt local : dépôt de l’agent sur son espace de travail (sous Cerise ou en local par ex.)
• Dépôt distant (remote) : dépôt correspondant situé sur la forge.

4.2 C’est quoi une forge ?

Définition Wikipédia :

En informatique, une forge est un système de gestion et de maintenance collaborative de texte.

C’est un espace où on peut archiver du code informatique (R mais pas que bien sûr) qui offre des fonctionnalités supplémentaires à Git comme :

• la gestion des tickets (issues) ;
  
• les merge requests ou pull requests ;
• un affichage plus agréable du dépôt avec une interface web ;
  
• la possibilité d’ajouter un wiki ;
  
• l’intégration et le déploiement continus…

4.3 Exemples de forges

Les plus connues : Gitlab, Github, Bitbucket…

Une forge peut être interne ou externe à un ministère.

• URL de la forge interne du MASA : https://forge.agriculture.rie.gouv.fr/gitlab/

• URL de la forge interne du MTECT : https://gitlab-forge.din.developpement-durable.gouv.fr/

• URL du MTECT sur Github : https://github.com/MTES-MCT

4.4 Dialoguer avec Gitlab

Pour travailler avec Gitlab, il faut mettre en place un mode d’authentification.

2 modes principaux existent :

• SSH
  
• HTTPS

Au MASA, une procédure de configuration existe et a été validée en mars 2024 pour établir la connexion entre Cerise et la forge gitlab interne. Celle-ci est basée sur le mode HTTPS et utilise le credential helper de Git qui évite d’avoir à re-saisir son mot de passe (ou token) à chaque action.

4.5 Les groupes dans les forges Gitlab

• Une forge Gitlab est structurée par groupe.
  
• Chaque groupe est constitué de projets (les fameux dépôts distants).
  
• Chaque groupe est associé à des utilisateurs dont chacun dispose d’un niveau de permissions sur les projets du groupe et sur le groupe lui-même.

4.6 Permissions et rôles dans Gitlab

• Les permissions se traduisent par plusieurs rôles qui sont détaillés dans la documentation de Gitlab(https://docs.gitlab.com/ee/user/permissions.html#project-members-permissions).

Ce qu’il faut retenir :

4.7 Le système de ticketing (issues)

Une issue est une tâche à effectuer : il peut s’agir tout autant de correctifs à apporter au projet que de fonctionnalités à ajouter.

Ouvrir une issue depuis Gitlab permet de :

– Discuter un point : il est possible d’échanger à plusieurs dans une issue pour définir comment la traiter.
– Assigner une tâche à une personne : lorsqu’on crée une issue, on peut assigner la tâche à une ou plusieurs personnes. Elle s’affiche alors sur le tableau de bord.
– Définir une échéance, classer une issue avec un label : le tableau de bord permet alors d’avoir une vision complète des issues en cours.

4.8 Activer les issues sur la forge interne du MASA

Par défaut, les issues ne sont pas activées à la création d’un dépôt sur la forge Gitlab du MASA.

Pour les activer, il faut :

• Cliquer sur Settings dans le bandeau de gauche puis General
• Cliquer sur le bouton Expand à côté de Visibility, project features, permissions
  
• Activer les issues :

• Enregistrer les changements :

4.9 Créer une issue

4.10 Afficher les issues sous forme de tableau (board)

Si vous utilisez des labels pour classer vos issues, Gitlab propose un affichage sous forme de tableau de bord qui permet de faire un suivi de projet sous forme de tâches.

Exemple :

4.11 Lier un dépôt local à un dépôt distant (1/2)

1ère étape commune à toutes les méthodes : création d’un dépôt vide sur la forge Gitlab

• Cliquez sur le bouton “New project” situé en haut à droite :

• Choisir “blank project” :

4.12 Lier un dépôt local à un dépôt distant (2/2)

• Renseigner le nom du projet, éventuellement une courte description, l’espace d’appartenance du projet dans la forge, son niveau de visibilité et penser à décocher l’option “Initialize repository with a README”. Puis cliquer sur “Create Project”.

4.13 Lier un dépôt local à un dépôt distant avec RStudio (1/3)

Créer un nouveau projet, puis choisir “Contrôle de version” :

4.14 Lier un dépôt local à un dépôt distant avec RStudio (2/3)

Puis choisir “Git” :

4.15 Lier un dépôt local à un dépôt distant avec RStudio (3/3)

4.16 Lier un dépôt local à un dépôt distant avec terminal (1/3)

La méthode à utiliser est différente selon les cas :

1. Vous voulez créer un nouveau répertoire dans votre working directory
   
2. Vous avez déjà un répertoire dans votre working directory

4.17 Lier un dépôt local à un dépôt distant avec terminal (2/3)

CAS 1 : création d’un nouveau répertoire

• Lancer le terminal dans le répertoire où on souhaite créer le nouveau dossier correspondant au dépôt distant (rappel sur comment faire)
  
• Taper la commande git clone <URL-depot-distant>

Par exemple :
git clone https://forge.agriculture.rie.gouv.fr/gitlab/damien.dotta/test.git - Ouvrir le nouveau répertoire et commencer à y travailler comme d’habitude en y créant un projet, des scripts…

4.18 Lier un dépôt local à un dépôt distant avec terminal (3/3)

CAS 2 : un répertoire existe déjà

• Lancer le terminal dans le répertoire non versionné que l’on souhaite lié au dépôt distant (rappel sur comment faire)
  
• Taper la commande git remote add origin <URL-depot-distant>

Par exemple :
git remote add origin https://forge.agriculture.rie.gouv.fr/gitlab/damien.dotta/test.git

4.19 Lier un dépôt local à un dépôt distant avec gitssp (1/2)

Le package gitssp peut également être utilisé pour effectuer la liaison.

Avantage : plusieurs branches distantes (developpement, recette et production) vont être créées en une seule instruction R.
Inconvénient : il y a 1 étape supplémentaire dans les pré-requis.

• Créer un projet .Rproj dans votre working directory (sans choisir “Contrôle de version”)
• Charger le package avec library(git=ssp)
• Lancer la fonction R ajouter_git()

4.20 Lier un dépôt local à un dépôt distant avec gitssp (2/2)

La fonction ajouter_git() comprend 2 arguments :

• origin : URL du dépôt distant (obligatoire)
  
• dossier : chemin vers le projet .Rproj que vous avez crée (facultatif car Si aucun dossier n’est précisé, les opérations vont se dérouler dans le dossier courant)

Par exemple :

ajouter_git(
  origin = "https://forge.agriculture.rie.gouv.fr/gitlab/damien.dotta/test.git",
  dossier = "~/test/"
)

4.21 Pousser les changements sur la forge avec RStudio

Après avoir ajouté vos changements à l’index et fait vos commits, vous pouvez “pousser” ces modifications sur la forge avec RStudio.

Dans l’exemple ci-dessous, après avoir committer une fois, RStudio me prévient dans l’onglet “Git” que je suis sur la branche developpement d’un commit :

Pour pousser ce commit sur le dépôt distant, il suffit simplement de cliquer sur le bouton

4.22 Pousser les changements sur la forge avec le terminal

Voilà comment pousser vos modifications sur la forge avec le terminal :

• Taper la commande git status pour récupérer l’information de la situation de notre dépôt local par rapport au dépôt distant.

• Taper la commande git push pour pousser ce commit sur le dépôt distant.

4.23 Utilisation des instructions git push et git pull

Dans les slides précédentes, une utilisation succinte des instructions git push et git pull a été faite.

Pour être sûr de maîtriser vos interactions entre le dépôt local et le dépôt distant, il est recommandé d’utiliser la syntaxe plus complète sur le modèle suivant :

• git push <alias> <nom-branche>
  
• git pull <alias> <nom-branche>

Exemples :
- git push origin developpement
- git pull origin production

4.24 Récupérer les changements en local avec RStudio

Pour récupérer sur le dépôt local des changements qui ont été poussés sur le dépôt distant avec RStudio.

Exemples de cas d’usage :
- Si un membre de l’équipe projet a poussé des modifications avant vous sur le dépôt distant.
- Si vous voulez récupérer les dernières modifications apportées à la branche distante suite à une merge request (voir plus loin)

Pour récupérer les commits depuis le dépôt distant, il suffit simplement de cliquer sur le bouton

Dans le cas d’un travail en équipe, il s’agit d’une opération à faire très fréquemment.
Git vous empêchera de pousser vos modifications sur le dépôt distant si vous n’avez pas au préalable récupérer toutes les dernières modifications qui s’y trouvent.

Message qui s’affiche dans ce cas :

4.25 Récupérer les changements en local avec le terminal

• Taper la commande git pull pour récupérer les derniers commits depuis dépôt distant.

4.26 Supprimer un dépôt dans Gitlab

4.27 Créer des tags avec le terminal

Les tags sont des étiquettes qui pointent vers des points spécifiques dans l’historique de Git.
Ils sont très utiles pour étiqueter les versions de vos projets (v0.1, v0.2…).

Pour créer un tag v0.1 sur le dernier commit :
git tag -a v0.1 -m "Message de tag"

Pour créer un tag v0.1 a posteriori (avec l’ID du commit) :
git tag -a v0.1 0af8bfd9 -m "Message de tag"

Pour partager les tags sur le dépôt distant :
git push origin --tags

Pour lister les tags :
git tag

4.28 Créer des tags avec gitlab

4.29 Revenir en arrière avec Gitlab (1/3)

L’interface de Gitlab permet de facilement se déplacer dans l’historique d’un projet versionné.

Par exemple :

4.30 Revenir en arrière avec Gitlab (2/3)

Cliquer sur le commit d’intérêt et dans la fenêtre qui en détaille le contenu, cliquer sur “Browse file” :

4.31 Revenir en arrière avec Gitlab (3/3)

On accède ainsi à l’état du projet tel qu’il était au moment du commit d’intérêt.

Remarque : des manipulations quasi-identiques permettent de faire la même chose avec les tags.

4.32 Revenir en arrière avec le terminal

Pour revenir à la version du tag v0.1 :
git checkout v1.0

Pour revenir à la version du commit 0af8bfd9 :
git checkout 0af8bfd9

Pour remonter de 4 commits dans le passé :
git checkout nom-de-branche~4

Pour revenir au présent :
git checkout nom-de-branche

4.33 Inverser un commit

La commande git revert SHA-commit permet d’inverser/de défaire ce qui avait été fait au moment du commit d’intérêt.

Attention, le git revert crée un nouveau commit (d’inversion c’est-à-dire que les lignes ajoutées seront supprimées et les fichiers supprimés seront recréés…).

4.34 Autres instructions Git

Il y a encore pleins d’instructions Git très utiles que vous découvrirez (ou pas) :

• git cherry-pick : sélectionner et appliquer un seul commit d’une branche à une autre
  
• git stash : mettre de côté les modifications d’un répertoire de travail
  
• git blame : montrer la révision et l’auteur qui ont modifié en dernier chaque ligne d’un fichier
  
• git rebase : réappliquer une série de commits d’une branche sur une autre branche
• git bisect : trouver par recherche binaire la modification qui a introduit une erreur
  …

5.1 Définition des branches

5.2 Quand créer une branche ?

On crée une branche pour :

• Continuer le développement de manière isolée sans altérer le reste du dépôt
  • Pour corriger un bug
    
  • Pour implémenter une nouvelle fonctionnalité
    
  • Pour refactorer le code…
• Isoler les différentes étapes du développement (une branche = un environnement)

5.3 Noms des branches

Concernant le noms des branches, une bonne pratique est d’utiliser la structure suivante : <categorie>-<nom>

5.4 Fermer une issue à partir d’une branche

Avec les forges Gitlab et Github, la fermeture des issues peut être automatiquement gérée via les messages de commit.

Pour cela, vous pouvez utiliser des mots-clés comme (au choix) :
- Close
- Fix
- Resolve
- Implement

En précisant le #numero-issue.

Exemple de message de commit :

feat: Ajout documentation utilisateurs

Close #31, en lien avec #29

5.5 Organisation au DEMESIS

5.6 Que deviennent les branches ?

Les branches permanentes persistent tout au long de la vie du projet.

Les branches temporaires :

• Apparaissent et disparaissent au fil de la vie du projet
  
• Ont une durée de vie limitée…
  
• … et doivent donc être détruites (manuellement ou suite à une fusion)

5.7 Savoir sur quelle branche on se situe

5.8 Lister les branches

5.9 Liste des branches et position sur les branches

Lorsqu’on affiche la liste des branches, la branche sur laquelle on se situe est identifiée avec un astérisque * devant.

5.10 Créer une nouvelle branche avec RStudio

Pour créer une nouvelle branche avec RStudio, il faut :

• Cliquer sur le bouton “Nouvelle branche” dans l’onglet Git

• Renseigner le nom de la nouvelle branche

Cette procédure va créer la nouvelle branche à la fois sur le dépôt local mais aussi sur le dépôt distant.

5.11 Créer une nouvelle branche à partir d’une issue Gitlab

Depuis l’interface Gitlab et à partir d’une issue, on peut créer une branche comme ci-dessous :

• Pour récupérer cette branche distante dans votre dépôt local, on fera un git pull dans le terminal ou RStudio.

5.12 Créer une nouvelle branche avec le terminal

Pour créer une branche dans le dépôt local avec le terminal, les commandes git branch et git checkout sont utilisées.

Créer une nouvelle branche “bugfix” dans le dépôt local :
git branch bugfix

Créer une nouvelle branche “bugfix” dans le dépôt local et se placer dessus :
git checkout -b bugfix

Synchroniser la nouvelle branche locale “bugfix” avec la branche distante :
git push -u origin bugfix

5.13 Créer une nouvelle branche avec gitssp

Créer une nouvelle branche

gitssp$create_branch_local("nom-de-branche")

Pousser la branche locale sur le dépôt distant

gitssp$push_branch_gitlab("nom-de-branche")

5.14 Changer de branche

5.15 Supprimer des branches locales

5.16 Supprimer des branches distantes

5.17 Fusionner deux branches avec le terminal

A VENIR

5.18 Fusionner deux branches avec Gitlab

A VENIR

5.19 Définition des conflits

Les conflits surviennent généralement lorsque deux personnes ont modifié les mêmes lignes dans un fichier, ou si un développeur a supprimé un fichier alors qu’un autre développeur le modifiait. Dans ces cas, Git ne peut pas déterminer automatiquement la version correcte.

Les conflits n’affectent que le développeur qui effectue le merge, les autres membres de l’équipe ne sont pas conscients du conflit. Git marquera le fichier comme étant en conflit et arrêtera le processus de merge.

Il incombe alors aux développeurs de résoudre le conflit.

*Source: Atlassian

5.20 Simulation d’un conflit

On se place dans la même configuration que dans l’application précédente : un mainteneur et deux/trois développeurs
Le mainteneur modifie le contenu de son fichier, puis commit et push les modifications
Sans faire de pull préalable, les développeurs modifient également le contenu du fichier du mainteneur, puis commit et push les modifications
Le push est rejeté pour la même raison que dans l’application précédente : les dépôts ne sont plus synchronisés, il faut pull les changements distants au préalable. Mais cette fois, le pull est également rejeté : il y a un conflit entre l’historique du projet distant et celui du projet local. Git nous indique qu’il faut résoudre le conflit avant de pouvoir modifier l’historique du projet.
Utiliser l’interface de RStudio pour résoudre le conflit, en choisissant la version du fichier que vous souhaitez conserver, puis commit/push les modifications
Comme dans l’application précédente, seul le développeur le plus rapide parvient à push. Les autres doivent répéter l’opération.

5.21 Repérer les conflits

Pour délimiter la zone de conflit, Git utilise les annotations suivantes :

• La ligne qui commence par <<<<<<< marque le début de la zone conflictuelle.
  
• Le marqueur ======= représente la frontière entre les deux zones à fusionner.
  
• La ligne qui commence par >>>>>>> délimite la fin de la zone conflictuelle.

5.22 Éviter au maximum les conflits

Quelques conseils :

• S’interroger sur la question de l’intersection des modifications et des fichiers potentiellement impactés lors de la planification des tâches
• Communiquer avec les autres membre de l’équipe pour dire qui travaille sur quoi
• La durée de vie des branches doit être la plus courte possible
• Modulariser son code (par ex. sous forme de fonctions)
  
• Résoudre les conflits le plus tôt possible et ne pas laisser la situation empirer.
  
• Faire des “bons” commits fréquemment

6.1 Packages R pour utiliser Git

• usethis - Un package R qui contient plusieurs fonctions très utiles pour les opérations courantes avec Git (par Posit).
  
• gert qui est un client Git pour R très efficace (par rOpenSci).

6.2 Bibliographie à consulter

En français :

• Documentation officielle de Git en français
  
• Les fiches consacrées à Git dans utilitr
  
• Formation aux bonnes pratiques avec Git et R par l’Insee
  
• Tutoriel Git par Atlassian

En anglais :

• Happy Git and Github for the useR par Jennifer Bryan (Posit)
  
• Cheatsheet - Using Git and Github with RStudio